<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<link rel="stylesheet" type="text/css" href="styles.css"/>
<title>iScriptDesign</title> <meta name="description" content="Abstract of the presentation"/>
<meta name="keywords" content="conference proceedings, keywords of the presentation"/>
</head>
<body>
<div class="article" lang="en">
 <div class="titlepage">
  <div>
   <div>
    <h2 class="title"><a id="d4e1"/>iScriptDesign</h2>
   </div>
   <h3 class="subtitle"><i>automate and parameterise your design</i></h3>
   </div>
   <div>
    <div class="authorgroup">
	 <div
	 class="author"><h3
	 class="author"><span class="firstname">Jeroen</span> <span class="surname">Dijkmeijer</span></h3>
 	  <div class="personblurb">
		<p>
		  Using SVG for materialization
                </p>
	  </div>
	</div>
   </div>
   <div>
    <div class="abstract">
	<hr/>
	<p class="title"><b>Abstract</b></p> <hr/>
	<p>
<h3>Abstract</h3>
<p>HTML was originally about presentation however it is legitimate to say that HTML's popularity is in great
part due to the possibility of interaction.  Interaction is hardly ever found in graphics, yet graphics and
dynamic graphics like movies enjoy a tremendous popularity. Imagine what would happen if you allow interaction
in graphics..</p>
<p>One application of interaction in graphics is the display of diagrams, by choosing between different
formats or range of values. Another yet unknown use case are template models. Do you still remember the days
that, as a youngster, you received paper models as birthday gifts from family and friends? Keep those paper
models in mind and..</p>
<div  class="itemizedlist">
<ul type="bullet">
<li>Imagine the possibility of changing some of your object's dimensions instead of scaling your complete
object (the steepness of your roof for example).</li>
<li>
Share it online so the whole world can benefit from it. </li>
<li>Benefit yourself from a library of tested and well documented components to use in you own template
models.</li>
<li>Do you still think that paper models can only be printed on paper?  Instead of printers bring laser
cutters, water cutters and cnc routers into action. Thanks to organizations like Fablab these toys become more
and more available to an increasing audience. Broaden your set of materials with plywood, glass, acrylic, iron
to name a few. Go beyond the paper and go beyond the model. Build some Thing. For real!</li>
</ul>
</div>
<p>iScriptDesign has been developed considering all of the above bullets and is developed using open and
license friendly frameworks and formats, leveraging the power of SVG in a not so traditional way. It has
proven to be an indispensable tool for me while constructing my own parameterizable furniture out of simple
sheets of plywood. I hope it will serve you as well!</p>
	</p>
	</div>
   </div>
  </div><hr/>
  </div>
  <div class="toc"><p><b>Table of Contents</b></p>
  <dl>
  <dt><span class="section"><a href="#L2T1_1">Overview</a></span></dt>
  <dt><span class="section"><a href="#L2T1_2">Shortcomings of the path</a></span></dt>
  <dt><span class="section"><a href="#L2T2_1">Script engine: introducing javascript</a></span></dt>
  <dt><span class="section"><a href="#L2T2_2">Unit tests</a></span></dt>
  <dt><span class="section"><a href="#L2T2_3">Artist's toolbox: iPath</a></span></dt>
  <dt><span class="section"><a href="#L2T2_4">Applications, future investigations and
  recommendations</a></span></dt>
  <dt><span class="section"><a href="#L1T3">Acknowledgments</a></span></dt>
  <dt><span class="bibliography"><a href="#Biblio">Bibliography</a></span></dt>
  </dl>
  </div>
	<div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear:
	both"><a id="L2T1_1"/>Overview</h2></div></div></div>
<p>
The paper you are about to read has mostly been fueled by the annoyances with SVG's path.  SVG is great for
designing, but is not very well suited for engineering and calculating blueprints. This is hard to understand
as SVG has embedded a powerful scripting engine, or can borrow calculation capacity from its containers, when
displayed.</p>
<p>  The investigations in this paper will overcome the path's shortcomings and keep its assets.
Therefor I will first explain my irritations with SVG's path.  Next I will research ways to mitigate its
liabilities. This research will focus on using the container's processing power and, on the other hand,
investigate the possibility to transform this power to SVG's internals.  While leveraging this script engine,
I'll introduce parametric or customizable online SVG. To make sure that modifications to iScriptDesign will
not damage existing code, a well proven paradigm from software development is introduced: unit testing.
Subsequently I will introduce in this paper an artist toolbox to script your design. This toolbox facilitates
programmers and artists alike: programmers' power at an artist's disposal, or vice versa artistic tools
available for programmers. Finally the last paragraph mentions possible applications of iScriptDesign.
Together with the artist's toolbox, iScriptDesign is opening up new ways for online fabrication, customizable
design and scripted sketches.
</p>
<p>
The intended audience has some working knowledge of Javascript and SVG and in particular SVG's XML
definition. Therefor the audience may recognize the same annoyances and appreciate the solutions this paper
will offer. To fully understand the shown solutions one can save and upload the example code snippets as a
single file (with .jsvg extension) into <a href="http://www.iscriptdesign.com">iScriptDesign</a> by either
clicking the right part (map) of the drop spot, or simply dragging the file into the drop spot (verified for
latest releases of Firefox and Chrome). Apart from the upload or drop functionality iScriptDesign will work
for all up to date browsers except for any version of Microsoft Internet Explorer.
</p>
<p>
iScriptDesign's code is available on <a href="http://code.google.com/p/iscriptdesign/">google code</a>. The
website is an almost exact copy of the HEAD of the SVN repository at google code.
</p>
<div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title" style="clear:
both"><a id="L2T1_2"/>Shortcomings of the path</h3></div></div></div>
<p>
<div class="orderedlist">
	<ol type="1"><li> SVG offers ways to interact with its internal data structure: the Document Object
Model (DOM). Unfortunately SVG's path, the general Swiss army knife of SVG sketching, is not well (if not
completely unequipped) to interact with or to modify it.  Currently best way to modify an existing path so it
can react to interactions is to retrieve its structure and split the contents of the "d" attribute on spaces
and change the value at the designated index of the array, (the result of the split). The dPath's DOM
equivalent, the pathSegList, has the same shortcomings as there is no possibility to label elements, which
should be modified when triggering by certain events.</li>
<li>The location driven meaning of parameters (in general even indexed numbers for x and uneven indexed
numbers for y) makes all parameters mandatory</li>
<li>SVG's path knows only the Cartesian coordinate system whereas the polar system may offer significant
increase in usability during design phase.</li>
<li>SVG's path looks like a relic from the past: verbosity, clarity and readability sacrificed for performance
and storage. It doesn't allow for comments nor does it give any hooks for substituting values. Invalid code is
not displayed, nor are the relevant error messages. The term graphical Assembler suits it best</li>
</ol></div><p> All the path's troubles aside it is also your one stop shop for most of your sketching needs:
lines, curves, arcs, regions etc. Considered the moving head or pen-like notion of the path, the path and
it's trail can be used to drive 2D or 2.5D cnc devices like laser cutters, water cutters or cnc routers, which
also have a moving "active" head.
</p>
<p>iScriptDesign offers a more modern approach to dPath's functionality by adding javascript to the well known
stack of pencil tools</p>
	<div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title" style="clear:
	both"><a id="L2T2_1"/>Script engine: introducing javascript</h3></div></div></div>
<p>iScriptDesign is comparable with a spreadsheet: modification of a cell may lead to a cascade of changes in
your worksheet. Likewise a change in a variable in iScriptDesign ignites a new evaluation of coordinates and a
redraw of your picture. In order to behave like a spreadsheet, the SVG file needs enhancements. To distinguish
between SVG and "enhanced" SVG, iScriptDesign files' have been called "jsvg" (Javascript SVG).  The jsvg file
contains normal SVG enhanced with tags to define "cells", to remain within the spreadsheet analogy. People
with a background in shell scripting or HTML templates, will not have difficulties finding similarities
between iScriptDesign's tags and directives in aforementioned technologies.</p>
<p>iScriptDesign distinguishes four types of spreadsheet cells (directives) each with their own use. All
directives will be removed before rendering the pictures (otherwise the SVG specification will be
broken). Before displaying examples the 4 directives are shortly described below.

<div class="itemizedlist">
<ul type="bullet">
<li style="list-style-type: disc"><p>--{} <br>Comment directive. This directive is for comments only will be
ignored inside SVG file.</p>
<li style="list-style-type: disc"><p>@{} <br>Control Directive.  This directive indicates input controls,
which will be subsequently attached to the input control panel. The value of the control is determined by the
end user and is stored in a variable. The name of this variable is denoted in the var attribute of this
directive. The directives itself are replaced with an empty string.</p><p>Currently 3 types of input fields
are possible: a slider, an numeric input field and text input field</p>
</li>
<li style="list-style-type: disc"><p>${ }$ <br>Evaluation directive. For initialisation of parameters and
 functions. Directive will be replaced with empty string.</p>
<li style="list-style-type: disc"><p>#{ } <br>Substitution directive. Contents will be evaluated and the
complete directive is replaced with the outcome of the contents' evaluation.</p>
</ul>
</div>
<p>
The order is also the order in which the directives are processed and replaced.
</p>
</p>
Below some less formal small examples. Although the main focus for iScriptDesign is the path, listing 1 will
demonstrate iScriptDesign's concepts for a basic SVG element, the rectangle. The height and the width of the
rectangle are the same (making it a square) and the value is the evaluation of 'size'. The variable 'size' is
defined inside the first directive, which does also display a slider. The sliders' state controls the value of
the variable size and a change to slider will redraw the whole image.
</p>

<pre class="programlisting">
&lt;svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="1100mm" height="600mm"> @{ var:size,
label:size, defaultvalue:150, size:3, type:slider, max:300, min:20 step:1 } 
&lt;rect x="50" y="50" width="#{size}" height="#{size}"/> 
&lt;/svg> --{listing 1. a rectangle}
</pre>
<p>
Instead of the XML element "&lt;rect...&gt;" the path's d-attribute (listing 2) can be used as you will see
the greater flexibility is at cost of readability.  The d-attribute generally describes a line (l) or movement
(m) across the x (uneven indices) and y (even indices) axis. Lowercase characters denote an relative movement
(dx and dy), uppercase characters denote an absolute movement (x,y). Listing 2 not only introduces the path and
its famous d-attribute, it also borrows the browser's javascript engine to calculate the coordinates of the
triangle corners.

</p>
<pre class="programlisting">
&lt;svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="1100mm" height="600mm"> 
@{ var:tri.size, label:size, defaultvalue:150, size:3, type:slider, max:300, min:20 step:1 } 
&lt;g fill="none" stroke="black">
&lt;path d="M 70 50 l #{tri.size} 0 l #{Math.cos(2*Math.PI/3) * tri.size} #{Math.sin(2*Math.PI/3) * tri.size} 
l #{Math.cos(4*Math.PI/3) * tri.size} #{Math.sin(4*Math.PI/3) * tri.size}"/> 
&lt;/g> 
&lt;/svg> 
--{listing 2, an equilateral triangle}
</pre>
<p>
The triangle above is introduced to display the use of Javascript's math functionality. You may verify that
the code above displays a "customizable" triangle in iScriptDesign, however it is not very readable and what
to do when you want to display an arbitrary number of triangles? Of course the code above can be copied and
pasted x times, however this will not contribute to readability or flexibility. Listing 3 shows a more
feasible approach by introducing a function.
</p>
<pre class="programlisting">
&lt;svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="1100mm" height="600mm"> 
@{ var:tri.size,label:size, defaultvalue:150, size:3, type:slider, max:300, min:20 step:1 }
${ triangle = function r(rsize) {                                                              --{ #1}
    return "l " + rsize + " 0 l " + Math.cos(2*Math.PI/3) * rsize + " " 
        + Math.sin(2*Math.PI/3) * rsize + " l " + Math.cos(4*Math.PI/3) * rsize 
        + " " + Math.sin(4*Math.PI/3) * rsize; 
    }; 
}$
&lt;g fill="none" stroke="black"> 
&lt;path d="M #{90 + 2*tri.size} 50 #{triangle(tri.size);}"/> 
&lt;/g>
&lt;/svg>
--{listing 3. a triangle function}
</pre>
<p>
A few things to note about the examples:
</p>
<div class="itemizedlist">
<ul type="bullet">
<li style="list-style-type: disc">
<p>In listing 3 the function triangle (at *) is defined embedded inside jsvg
but could as well have been defined inside an external library, well documented and tested. </p></li>
<li style="list-style-type: disc"><p>Also note the difference for parameters in listing 1 and 2 versus 3: an
an ordinary parameter versus an object with attributes. The object with attributes will prevent name
collisions and keeps your code cleaner, it is therefor by far more recommended. It is possible to use semi
endless nested object attribute definitions for your variable declarations.</p></li>
<li style="list-style-type: disc"><p>Currently the curly bracket matching is not the most sophisticated
 routine and is incapable of matching nested curly brackets <br> (#{ function(parameter1, parameter2, { att1:
 "value", att2: 3 }} This will fail because the first closing curly bracket is matched against the first
 opening bracket). Using nested curly brackets (for additional settings) can only be done by escaping the
 inner nested closing curly bracket (#{ function(parameter1, parameter2, { att1: "value", att2:
 3 <b>\</b>}})</p></li>
<li style="list-style-type: disc"><p>Experience with iScriptDesign learned me that absolute movement is hardly
used within functions. Most common was to point the pen to a certain position and from there start "sketching"
either with functions or plain path code.</p></li>
<li style="list-style-type: disc"><p>The premature performance optimization pitfall has been very successfully
circumvented</p></li>
<li style="list-style-type: disc"><p> While the introduction of a function in listing 3, may look like a
successful exercise of tackling at least some of the shortcoming of the path, it is still very close to the
original path. Path codes are moved inside functions where they are as unreadable as outside the
function. Logic inside directives is hard to debug and there is no clean separation of your code and the
view.</p>
</ul>
</div>
<p>
Especially last bullet point is the reason why iScriptDesign was taken back to the drawing board. Having all
the programming power at your hands, why not leverage its usage even more and create a path object which
offers the same capabilities as SVG's own original path, enhanced with more verbose functionality and features often needed
by designers and developers?</p></li>

</p>
</div>
<div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear:
both"><a id="L2T2_2"/>Unit tests</h2></div></div></div>
<p>
Before re-factoring and introducing new functionality, you must secure your accomplishments. A well known way
of securing code is the use of unit tests: isolating code (functions or methods) and check the result of your
programming logic against verified output obtained earlier. The greater part of your code is covered by
unit-testing, the more you're guarded against breaking logic when re-factoring or extending your existing code
base.</p>
<p>The logical input for SVG (hence the output of iScriptDesign's functionality) is simple text, easy enough to
do comparisons against and define unit-tests on them.</p><p>  A few test frameworks for javascript are
available. IScriptDesign is using Jasmine, at the moment of selection the most vivid project. A typical Jasmin
unit-test looks like:
<pre class="programlisting">
  it ("should form a symmetrical line", function() {
       expect(symmetry([[{x:30,y:20},{x:20,y:30},{x:40,y:30}]],0)) 
          .toEqual("c 30 20 20 30 40 30 c 20 0 10 -10 40 -30 "); 
  }); 
--{ listing 4a, A unit test }
</pre>
<p>
Although seasoned programmers may find the omission of the well known "assert statements" confusing, I think
that the "expect(..).toEqual(..)" terminology contributes to readability for the less seasoned
programmers. When the function "symmetry" is modified and it does not produce the outcome we specified in the
toEqual() part, this particular unit test fails. You'll be able to identify and locate the problem
faster. Once the problem is found you should reconsider your code modifications (or the reference outcome for
your unit test). We can of course also use a unit test for double checking idempotent logic:</p>
<pre class="programlisting">
  it ("should check idem-potency", function() { 
             expect(myPath.rotate(myPath, Math.PI/4).reverse(myPath).dPath(1))
           .toEqual(myPath.reverse(myPath).rotate(myPath, Math.PI/4).dPath(1)); }); 
--{ listing 4b Check idem-potency in code. (code will be explained in detail below). }
</pre>
<p>
A unit test may of course also be used to guarantee behaviour of new functionality (introduced below).
</p>
<pre class="programlisting">
  it ("should form a symmetrical line", function() {
       expect(symmetry([[{x:30,y:20},{x:20,y:30},{x:40,y:30}]],0)) 
           .toEqual(new iPath().line(30, 20).line(20, 30).line(40, 30)
           .mirror({x:1}).dPath(1)); }); 
--{ listing 4c checking new code against old code. (The code will be explained in detail below). }
</pre>
 <p>All available unit tests for iScriptDesign can be viewed at:<a href="http://www.iscriptdesign.com/test/spec/">http://www.iscriptdesign.com/test/spec</a>
</div>
<div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear:both"><a id="L2T2_3">Artist's toolbox: iPath</a></h2></div></div></div>
<p>
While iScriptDesign has served me well in creating real materialized artifacts, its deficiencies became more
and more apparent. Mainly because dPath appears as a relic from times long past when readability was a
sacrifice to performance and memory. Replacing strings within dPath with directives is fighting symptoms and
it remains a suboptimal solution: obscure paths remain, errors are easily made and debugging is difficult.</p>
<p>After working more thoroughly with iScriptDesign, best practice appeared to be taking out long strings of
dPath coordinates and replace them with functions, instead of mixing in few directives between dPath's
coordinates. Reusability of those functions, is a big advantage and putting those functions in test sets
(generally called test suites) secured outcome when modifying them for functionality or performance.
</p>
<p>
Above described difficulties became more and apparent and iScriptDesign became more and more a liability
while scripting my design. With the gained insights, I assembled a wish-list for iScriptDesign++.
<br>It must (be):
</p>
<div class="itemizedlist">
<ul type="bullet">
<li style="list-style-type: disc">
		<p>Verbose</p></li>
		<li style="list-style-type: disc"><p>Easy to implement for me</p></li>
		<li style="list-style-type: disc"><p>Easy to you use for you</p></li>
		<li style="list-style-type: disc"><p>Make unspecified variables default to zero</p></li>
                <li style="list-style-type: disc"><p>Incorporate turtle graphics, a well kept child hood memory.</p></li>
                <li style="list-style-type: disc"><p>In combination with turtle graphics, allow polar coordinates.</p></li>
		<li style="list-style-type: disc"><p>Offer an intuitive way for common tasks like reversing, mirroring (over an arbitrary
		vector), rotating, scaling and skewing</p></li>
                <li style="list-style-type: disc"><p>Redefine a cubic bezier curve so that second control point is relative to end
                point.</p></li>
		<li style="list-style-type: disc"><p>Not tied to SVG alone, support vector dependent devices like cnc routers, water/laser
		cutters, embroidery machines etc</p></li>
		<li style="list-style-type: disc"><p>Derived from above: path orientated</p></li>
		<li style="list-style-type: disc"><p>Have a new name. iScriptDesign is not very catching</p></li>
        </ol>
</div>
<p>Order is not correlated to priority, but last 2 points were easiest to solve: it's called iPath. iPath does not replace iScriptDesign instead it is a new module which should be used inside iScriptDesign</p>
<p>Positive experience with jQuery's method chained programming paradigm and earlier experiences with arrays led to
the core of iPath: a wrapper object around the array. Lines, moves and bezier curves are pushed on the array
as javascript objects with methods which support method chaining. Predefined methods make it also easier for
javascript editors to allow for code completion.</p>
<p>  Let's get back to our first example in listing 1 (our
rectangle) and rewrite it to iPath, to get a basic idea:
</p>
<pre class="programlisting">
&lt;svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="1100mm" height="600mm"> 
@{ var:rect.size, label:size, defaultvalue:150, size:3, type:slider, max:300, min:20 step:1 }
&lt;g fill="none" stroke="black"> 
&lt;path d="M #{90 + 3*rsize} 50 #{myPathRect.dPath();}"/> --{ #1 } 
&lt;/g>
${ myPathRect = new iPath() -- { #2 } 
    .line(rect.size,0) 
    .line(0,rect.size) 
    .line({x:-1*rect.size})
    .line({y:-1*rect.size}); }$
--{ Listing 5. rectangle with iPath. }
</pre>
<p>
At --{ #2} a new iPath is constructed leaving us with an new iPath object. Immediately after the construction
we can invoke methods on the same object. In listing 5 the line method is called 4 times.  A more graphical
interpretation commands an imaginary pen or cursor that it should, from its starting position, draw a line
east, south, west and north. Parameters are passed in a way which should feel familiar by now. Also pay
attention to the way arguments are passed in, as ordered x,y pair or as a data object (with x and y
attributes). The latter offering the option of defaulting unspecified parameters to 0 (zero).  To get a dPath
representation (and a the actual square) the initial position of the cursor is set at -- { #1 } and the call
dPath(significance) at the same line suffices to create the actual figure.
</p>
<p>
  Internally all movements are pushed as objects on the array and objects for movements all need to have x &
  y attributes in a Cartesian context, or a (alpha) and r (radius) attributes in a polar context. While traversing and rendering
  the path, the location and the direction (heading) of cursor is tracked. Below is a list of the
  functionality currently available in iPath:
</p>
<div class="orderedlist">
	<ol type="1">
		<li><p>iPath.move(x,y) | move({x:p1, y:p2}): adds a relative movement to the iPath;</p></li>
		<li><p>iPath.Move(x,y) | Move({x:p1, y:p2}): adds an absolute movement to the iPath</p></li>
		<li><p>iPath.line(x,y) | line({x:p1, y:p2}): adds a relative line to the iPath</p></li>
		<li><p>iPath.Line(x,y) | Line({x:p1, y:p2}): adds an absolute line to the iPath</p></li>
		<li><p>iPath.smooth(weight, cp2x, cp2y, x, y) : adds an bezier curve to the path, which takes
		directions of last element, the length is specified by weight</p></li>
		<li><p>iPath.bezier(cp1x, cp1y, cp2x, cp2y, x, y) | iPath.bezier(cp1x, cp1y, x, y) : adds a
		cubic or quadratic curve to the iPath.</p></li>
		<li><p>iPath.reverse() : returns the reversed iPath (modifies iPath)</p></li>
		<li><p>iPath.reverse(arg) : returns the reversed the arg (if arg is of type iPath, arg and
		iPath are untouched)</p></li>
		<li><p>iPath.skew(skewfactor) : returns the skewed iPath (modifies iPath)</p></li>
		<li><p>iPath.skew(skewfactor, arg) : returns the skewed the arg (if arg is of type iPath, arg
		and iPath are untouched)</p></li>
		<li><p>iPath.reflect({x:0, y:0}) : returns the reflected iPath in the passed in vector
		(modifies iPath)</p></li>
		<li><p>iPath.reflect({x:0, y:0}, arg) : returns the reflected arg (if arg is of type iPath,
		arg and iPath are untouched)</p></li>
		<li><p>iPath.rotate(angle) : returns the angle radians rotated iPath (modifies
		iPath) </p></li>
		<li><p>iPath.rotate(angle, arg) : returns the rotated arg (if arg is of type iPath, arg and
		iPath are untouched)</p></li>
		<li><p>iPath.concat(other) : returns an iPath concatenated with another iPath</p></li>
		<li><p>iPath.turtleLine({a: alpha, r:radius}): adds a polar line to the iPath</p></li>
		<li><p>iPath.turtleMove({a: alpha, r:radius}): adds a polar movement to the iPath</p></li>
		<li><p>iPath.turtleBezier({a:angle, r:radius, cp1:{a:angle, r:radius}, cp2:{a:angle,
		r:radius}})</p></li>
		<li><p>iPath.repeat(nrOfTimes)</p></li>
		<li><p>iPath.dPath(significance) : returns the stringified version of the iPath</p></li>
        </ol>
</div>
<p>
The transformation methods (rotate, skew, reflect, reverse) are in 2 flavors one accepting only transformation
arguments and second the same function accepting an iPath argument extra. The First version modifies the
object self. The second leaves the argument and the main object untouched and returns a cloned copy of the
passed in argument with the transformation applied. The unit test below shows that the original path indeed
has been modified.
<pre class="programlisting">
  it ("should test a modified iPath", function() { 
       var rotateTest = new iPath().line(5,5).line(5,-5);
       expect(rotateTest.rotate(Math.PI/4).dPath(3)) .toEqual(" l 0 7.071 7.071 0");
       expect(rotateTest.dPath(3)).toEqual(" l 0 7.071 7.071 0"); }); 
// Listing 6a testing a modified Path.
</pre>
<p>
Next unit test shows that the original rotateTest object is untouched
</p>
<pre class="programlisting">
  it ("should test an unmodified iPath", function() { 
       var rotateTest = new iPath().line(5,5).line(5,-5);
       expect(rotateTest.rotate(Math.PI/4, rotateTest).dPath(3)) .toEqual(" l 0 7.071 7.071 0");
       expect(rotateTest.dPath(3)).toEqual(" l 5 5 5 -5"); }); 
// Listing 6b testing a unmodified Path.
</pre>
Below some examples leveraging iPath's functionality:<br> 
A heart (a symmetrical form) can be created with
code like:
</p>
<pre class="programlisting">
${ (heart = new iPath()).bezier(0, -50, -150, -200, 0, -120)
     .concat(heart.reverse(heart).reflect({y:1})); 
}$
&lt;g stroke="black" stroke-width="0.8" fill="none" transform="scale(0.6)"> 
&lt;path id="heart" d="M700 300 #{heart.dPath(3); }"/> 
&lt;/g> 
-- { listing 7 }
</pre>
<p>
At first sight it looks like a cumbersome exercise, however you may feel more at ease once you realize that
only the hearts' left part is designed as a bezier curve and the rest of the heart is mirrored (in the y axis)
concatenation of the first part. Changing the left parts' bezier curve will update the right part without any
effort, keeping the symmetry in place. Also worth noting is the fact that the drawing of the heart above is
cnc friendly: the pen (or operating head) does not need to be taken from the material during action.  Of
course arguments may still be passed to iPath method's arguments, so that they will respond to user generated
events like sliders or input fields.
</p>
<p> The next example will introduce Turtle Graphics and Polar coordinates. Turtle graphics has been introduced
as a part of the logo programming language, a language aimed at children and capable of visualizing a stateful
cursor (the turtle) which listens to very simple instructions like forward, turn, penUp and penDown. With
repetition and conditional statements it was a fun way of creating impressive looking graphics. Turtle
graphics is a synonym for polar coordinates, which may be more appealing to the professional audience. A
typical use case for turtle graphics (or polar graphics) is a regular polygon with n sides and a variable
radius:</p>
<pre class="programlisting">
&lt;svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="1100" height="600"> 
@{ var:polygon.n,label:corners, defaultvalue:8, type:slider, max:60, min:3, step:1, size:3 } 
@{ var:polygon.r, label:radius, defaultvalue:8, type:slider, max:300, min:10, step:10, size:3 } 
${ polygon.iPath = new iPath()
     .turtleLine({a:Math.PI*2 / polygon.n, r: polygon.r * Math.sin(Math.PI/polygon.n) * 2 }).repeat(polygon.n); }$ 
&lt;g stroke="red" stroke-width="0.8" fill="none" transform="scale(0.6)"> 
&lt;path id="loop1" d="M400 400
#{polygon.iPath.dPath();}"/> 
&lt;/g> 
&lt;/svg> --{ listing 8 regular polygon }
</pre>
<p>
The last repeat statement is subject to change: it is more logical to introduce the repeat statement
upfront. This way it can be used as a conditional statement (0-n) instead of (1-n) and it will be possible to
use a counter while repeating the statements. Also note the way for directing the turtle (opposed to the x and
y coordinates): {a: for angle and r: radius distance}. First the turtle turns "a" radians (a turtle initial
heading is 0 radians corresponding to 3 o'clock) and than the turtle moves r steps forward.
</p>
<p>
When introducing a new idiom as above, it allows to "modify" some of SVG's less understood features, as the
capabilities to transform it back to the original format are close at hand. One of the most counter intuitive
format in SVG (in my opinion) has always been the cubic bezier curve, where the second control point is
relative to the start and not to the end point. This behaviour has been corrected in the turtleBezier
function. The second control point is relative to the endpoint and copies the heading, which is set after the first
control point, so an angle of 0 in cp2 makes the endpoint's tangent parallel to the tangent of the start
point. Test listing 9 to get a feeling.
</p>
<pre class="programlisting">
&lt;svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="1100" height="600"> 
@{ var:angie, label:angle, defaultvalue:0, type:slider, max:3.141592, min:-3.1415921, step:0.05, size:3 } 
@{ var:cp1Angie, label:angle cp1, defaultvalue:0, type:slider, max:3.141592, min:-3.1415921, step:0.05, size:3 } 
@{ var:cp2Angie, label:angle cp2, defaultvalue:0, type:slider, max:3.142592, min:-3.1415921, step:0.05, size:3 } 
${
turtleBezier = new iPath().Move(400, 200).line(200, 0)
    .turtleBezier({ a: angie, r: 200, cp1: { a:cp1Angie, r:300 }, cp2: {a:cp2Angie, r:300} }); 
}$ 
&lt;g stroke="blue" stroke-width="0.8" fill="none" transform="scale(0.6)"> 
&lt;path id="bult2" d="#{ turtleBezier.dPath(3) }"/> 
&lt;/g> 
&lt;/svg> 
--{ listing 9 turtle bezier }
</pre>
<p>The close reader must have noticed that almost all items in the wish list, introduced at the beginning of
this section, have been ticked off. The ones still open:
<div class="itemizedlist">
<ul type="bullet">
   <li style="list-style-type: disc">it must be easy to implement for me: Yes it was (I learned some Javascript as well)</li>
   <li style="list-style-type: disc">It must be verbose</li>
   <li style="list-style-type: disc">It must be easy to use for you</li>
</ul>
</div>
<p>Last two open bullets are left as judgement to the audience.
</p>
</div>
<div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear:
both"><a id="L2T2_4"/>Possible applications, future investigations and recommendations</h2></div></div></div>
<p>
The concepts of iPath and iScriptDesign should be clear by now. Last paragraph is dedicated to speculation
about future possibilities and applications for iScriptDesign. iScriptDesign's original target was an online
sketch spreadsheet for designing real life artifacts. But while working on and with iScriptDesign, I realized
that there are many more applications for it. Below a selection:
</p>
<div class="orderedlist">
	<ol type="1"><li style="list-style-type: disc"><p> Potentially iPath can return more than SVG's dPath strings a PathSegList. Outside SVG
iPath may also produce: gcode, DXF, DST (a format used for embroidery) or other vector like formats. Extra settings like
milling radius correction, material thickness speed and other typical cnc parameters can be fed in as
javascript objects and if necessary can be added as meta-data to movements or complete iPath's.
</p></li>
<li style="list-style-type: disc"><p>Reverse engineer an existing dPath into a Cartesian or polar iPath object by reading in a dPath
string</p></li>
<li style="list-style-type: disc"><p> iPath is now only capable of reacting to user input (via input fields or sliders), imagine other
inputs, like audio streams captured from a microphone, or a music clip within the web page.
</p></li>
<li style="list-style-type: disc"><p>In addition to the possibility above, animation of iScriptDesign and iPath can be realized when values 
of parameters can be controlled by predefined time lines, creating simple yet effective
animated sketches.
</p></li><li style="list-style-type: disc"><p>Currently iScriptDesign is only available as a big page size website. A small arbitrary sized panel
like an JPG, GIF or PNG images but now with a script as image source and some user input controls attached to
it.
</p></li>
<li style="list-style-type: disc"><p>Visually programming graphics has been very rewarding for me during my childhood. I do expect that
iScriptDesign will be a big asset in education especially when the programmed objects can be visualized with
the aid of svg and materialized with cnc equipment.
</p></li>
<li style="list-style-type: disc"><p>It is pointless to implement above bullets without a proper standard.
I do hope that this paper contributes to an initiative for an addition to the SVG specification: a scriptable path. So that
iScriptDesign becomes uScriptDesign!
</p></li>
</ul>
</div>
	<div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear:
	both"><a id="L1T3"/>Acknowledgments</h2></div></div></div>
<p>
My wife Ellen<br> many users of stackexchange sites, in particular stackoverflow and English.stackexchange<br>
</p>
</div>
	<div
	class="bibliography"><div
	class="titlepage"><div><div><h2 class="title"><a id="Biblio"/>Bibliography</h2></div></div></div>
		<div class="biblioentry"><a id="BIBLIO1"/><p>[<abbr class="abbrev">REF1</abbr>]
			<span class="title"><i>turtle graphics</i>. </span>
			<span class="publisher">
				<span class="publishername">Publisher name. </span>
			</span>
			<span class="title"><i>Jasmine</i>. </span>
			<span class="publisher">
				<span class="publishername">Publisher name. </span>
			</span>
		</p></div>
	</div>
</div></body></html>

<!-- LocalWords: dPath's rect rsize turtleLine turtleMove turtleBezier Fablab jsvg --> <!-- LocalWords:
 iSciptDesig pathSegList dPath toEqual jsvg SVN svg jQuery's penUp penDown --> <!-- LocalWords: versa Firefox
 xmlns defaultvalue iscriptdesign's svg xmlns defaultvalue dx dy --> <!-- LocalWords: tri dx dy cp
 Javascript's rSize MVC myPathRect cp arg concat engish --> <!-- LocalWords: nrOfTimes stringified
 uScriptDesign stackexchange att myPath Fablab SVN --> <!-- LocalWords: stackoverflow google --> jQuery's
 myPathRect <!-- LocalWords: arg skewfactor concat rotateTest stateful penUp penDown bult --> <!-- LocalWords:
 angie jpg -->
